An ATM transmission is shown in FIG. 1 as a cell stream 10 composed of a series of cells 11. In the standard ATM format, each cell is comprised of 53 octets, of which 5 octets comprise the header 12 and 48 octets comprise the information field 14. As shown in FIG. 1, the header 12 includes routing information identifying how the header 12 and information field 14 are to be routed as an ATM transmission.
A standard cell header for a user-to-network interface is shown in FIG. 2. As shown, the header 12 comprises 5 octets. The cell header 12 is divided into various sub-headings according to the following nomenclature:
GFC Generic Flow Control PA1 VPI Virtual Path Identifier PA1 VCI Virtual Channel Identifier PA1 PTI Payload Type Identifier PA1 CLP Cell Loss Priority PA1 HEC Header Error Control
The generic flow control, payload type, cell loss priority, and header error control sub divisions of the header 12 have known functionalities to those of ordinary skill in the art.
FIG. 3 shows a prior art transmission path 30 for an ATM transmission. The ATM transmission path supports virtual paths VP31, VP32, and VP33 (plus or minus any number of additional virtual paths). Each virtual path 31-33 begins at a beginning point within the transmission path 30 and ends at an ending point somewhere along the transmission path 30. Within each of the virtual paths is a number of virtual channels, VC35, VC36 and VC37 (plus or minus any number of additional virtual channels).
Referring again to FIG. 1, each header 12 contains information identifying how the cell 11 associated with the header 12 will be routed through the transmission path 30, and specifically through the virtual channels (VC) and virtual paths (VP) of FIG. 3. The header fields which provide this routing information are the virtual path identifiers and virtual channel identifiers of FIG. 2, which tell the switching circuits within the transmission path 30 which virtual paths and virtual channels the particular cell 11 is to be routed through.
Within the above-described ATM context, the presently preferred embodiments of the invention are realized. Specifically, this preferred embodiment relates to a particular type of server category defined by the ATM Forum as "ABR." ABR is a protocol between an ATM network and user terminals to control the cell rate of each connection, in order to avoid overload in the network. The protocol is carried in special Resource Management cells that are inserted in the user cell stream (FIG. 4b) at regular intervals.
Several different service categories have been defined by the ATM forum. Constant Bit Rate, CBR, is used for real time applications with constant bit rate, e.g. telephony and other audio services. A maximum delay for CBR cells must be guaranteed by the network. For Variable Bit Rate, VBR, a maximum and a sustainable bit rate is defined, i.e., a source may send cells at the maximum bit rate for some defined maximum time, but the mean over a longer time must not exceed the sustainable bit rate. Two VBR categories are defined: one real time, with a maximum delay requirement, and one non-real time.
The idea with ABR is to use the bandwidth left over after CBR and VBR cells have been served, and distribute this bandwidth fairly among the active connections. ABR provides a flexible and efficient traffic service for, in particular, datacom applications. It has LAN-like performance in terms of shared medium properties and assured fairness of the available bandwidth. A user should be able to start up at a high predefined rate any time without any start-up delay and, when a node is congested, the network will tell the sources to decrease their rate, or increase the rate if there is bandwidth available.
Cell Delay Variation (CDV) is not controlled in this service and it is therefore not intended to support real-time applications. On the establishment of an ABR connection, the user specifies to the network both a maximum required bandwidth or Peak Cell Rate (PCR) and a minimum usable bandwidth or Minimum Cell Rate (MCR). The network must guarantee a bandwidth of at least MCR and the user should not send cells at a rate that exceeds PCR.
The basic technique for the network to control the source transmission rate is by telling it the maximum rate it can send at and not overload the network. ATM Forum has defined a source, a switch and a destination behavior for ABR as shown in FIG. 4b. The sources send Resource Management (RM) cells and the destinations will turn around them. Three levels of switch behavior are defined.
The simplest form is the binary, or EFCI (Explicit Forward Congestion Indication) switch, that sets the EFCI bit field in the cell header of a traffic cell when the switch is near congestion. The destination will then turn around the indication to the source by setting the Congestion Indication (CI) bit in the RM cell.
The relative rate switch will set the CI bit directly in backward RM cells, instead of setting the EFCI bit in forward cells. This will speed up the time from when a switch gets congested until the resources are notified.
The third, and most advanced, type of switches is the Explicit rate switches that updates the Explicit Rate (ER) field of the backward RM cells with a computed fair rate. A source will decrease its rate continuously for every cell sent and when receiving an RM cell the output rate is set to the one in the ER field, or increase it with a predefined factor if CI=O. A source will inform the network of its Current Cell Rate, CCR, in a field in the forward RM cell. At start up, a source will use a predefined Allowed Cell Rate, ACR.
The rate based approach will support all these types of switches and make it possible for them to coexist in a network. The binary and relative rate switches will not affect too much on performance if there are only a few layers of them but an ABR network based on only EFCI switches will have certain drawbacks. Given the same level of congestion at all the switches, connections traveling more hops have a higher probability of having their EFCI bit set than those traveling a smaller number of hops. This results in connections with many hops having very few opportunities to increase their rates and consequently their throughputs are starved. Another problem is that it may take several round trips before the sources have decreased their rate enough and hence larger buffers will be required (compared to a network with ER switches).
The switch vendor decides how to mark RM cells so as to achieve the least buffer requirement, the best link utilization, maximum fairness and maximum responsiveness.
In FIG. 4b, the source 43 performs certain operations, including sending forward RM cells every N.sub.m cell. The source 43 can also decrease the rate continuously, or it can increase the rate additionally when a backward RM cell is received with a Congestion Indicator=0 or set the rate to receive the Explicit Rate.
The switch 44 has certain options during congestion. It can set the EFCI-bit in forward RM cells, set the Cl-bit in backward RM cells, and set the Explicit Rate field in the backward RM cell (set to "fair share" in the switch).
Finally, the destination 45 performs certain operations, including looping back the RM cells by setting the "forward" indicator to "backward" in the cell. It can also set the CI to the EFCI value of the latest received cell.
The ATM Forum thus defines two types of Resource Management cells: forward Resource Management cells and backward Resource Management cells. Forward Resource Management cells are sent in the same direction as the user cell stream (FIG. 4b), i.e. from a source to a destination. The forward Resource Management cells carry information about the current cell rate that can be extracted by a switch 42 and 44 along the path. These forward cells are used in calculating the explicit cell rate.
The backward Resource Management cells are sent in the reverse direction, but along the same virtual path, i.e., passing the same switching nodes. The backward cells are sent from the destination once the destination has received a forward RM cell. The explicit cell rate is inserted in the backward Resource Management cells for delivery to the source. When the source receives a backward Resource Management cell containing the explicit cell rate, it will adjust its rate to the value identified in the backward Resource Management cells.
FIG. 4a illustrates a prior art ABR implementation. The Figure shows a switch core 40 to which two switch ports 41 and 42 are connected (there could of course be many more switch ports connected to the core). Each switch port is divided into an ingress port 41a and 42b and an egress port 42a and 41b. Cells arrive from an external link to an ingress port, are switched through the switch core to an egress port and then transmitted out on a link. An ABR connection will have a forward direction and a backward direction. User cells and forward RM cells will enter the ingress part of an upstream switch port and exit through the egress part of a down stream port. Backward RM cells will enter the ingress part of a downstream switch port and exit through the egress part of an upstream port. The terms upstream and downstream are defined per connection (i.e., a switch port is upstream for some connections and downstream for other connections).
In a prior art implementation, the upstream and downstream switch ports execute the ABR ER algorithm independently based on local information only (queue status in the port itself and the CCR values from forward RM cells). A backward RM cell will first pass the downstream switch port and then the upstream port, and may be modified by both ports.
Different algorithms have been defined for calculating the explicit rate value: EPRCA, CAPC-2, ERICA +, etc. They differ in their complexity and efficiency. A common feature is that they make use of the current queue length in the switch when calculating the explicit rate value (and other values as well).